home *** CD-ROM | disk | FTP | other *** search
/ iBrowse Update Disc / iBrowse Update Disc.iso / distrib / man / Manuals / UserGuide / AppNote
Text File  |  1996-10-04  |  31KB  |  768 lines

  1. -----------------------------------------------------------------------------
  2. 4th October 1996
  3. -----------------------------------------------------------------------------
  4. Engineering Support Application Note
  5. Number: 295
  6. Issue: 2.02
  7. -----------------------------------------------------------------------------
  8. Introduction to StrongARM and Programming Guidelines
  9.  
  10. -----------------------------------------------------------------------------
  11. Notes: 
  12. This Application Note introduces the StrongARM SA-110 processor, and details
  13. the issues which arise owing to the differences between it and earlier ARM
  14. processors. We also introduce RISC OS 3.7, and describe its enhancements
  15. over RISC OS 3.6.
  16. -----------------------------------------------------------------------------
  17. Applicable Hardware: 
  18. Any system equipped with RISC OS 3.7 
  19.  
  20. Related Application Notes: 
  21. None
  22.  
  23. -----------------------------------------------------------------------------
  24. Copyright (C) 1996 Acorn Computers Limited 
  25.  
  26. Every effort has been made to ensure that the information in this leaflet is
  27. true and correct at the time of printing. However, the products described in
  28. this leaflet are subject to continuous development and improvements and
  29. Acorn Computers Limited reserves the right to change its specifications at
  30. any time. Acorn Computers Limited cannot accept liability for any loss or
  31. damage arising from the use of any information or particulars in this
  32. leaflet. Acorn, the Acorn Logo, ART, the ART logo, Acorn Risc PC, ECONET,
  33. AUN, Pocket Book and ARCHIMEDES are trademarks of Acorn Computers Limited.
  34.  
  35. ARM is a trademark of Advanced RISC Machines Limited.
  36. All other trademarks acknowledged.
  37. -----------------------------------------------------------------------------
  38. Engineering Support
  39. Acorn Risc Technologies
  40. Acorn House
  41. 645 Newmarket Road
  42. Cambridge
  43. CB5 8PB                                           
  44. -----------------------------------------------------------------------------
  45.  
  46. Introduction to the StrongARM                        
  47. -----------------------------
  48. The StrongARM 110 is a new high-performance processor from Digital
  49. Semiconductor. It offers performance improvements over the ARM710 ranging
  50. from 100% to 1000%, depending on the application.
  51.  
  52. A StrongARM processor card will available for the Risc PC later this year.
  53. It will come with a new ROM set containing RISC OS 3.70, a new
  54. StrongARM-compatible version of RISC OS. These documents provide information
  55. on writing software, and modifying existing software, for StrongARM-based
  56. machines.
  57.  
  58.  
  59. Significant StrongARM features
  60.  
  61.     * 202MHz core clock
  62.       
  63.     * 5-stage pipeline (Fetch, Issue, Execute, Buffer, Write)
  64.       
  65.     * Separate 16K write-back data cache and 16K instruction cache
  66.       
  67.     * 8 entry write buffer, each entry holding 1-16 bytes
  68.       
  69.     * Fast 32 and 64 bit result multiply instructions
  70.     
  71.     * Averages fewer cycles per instruction than previous ARMs
  72.       
  73.  
  74. Incompatibilities
  75. -----------------
  76. The StrongARM has two significant differences from previous ARMs that can
  77. affect existing programs. Firstly, the split caches mean that instructions
  78. written into memory may linger in the data cache, and not be in real memory
  79. when the instruction cache comes to fetch them. Likewise if some code is
  80. already in the instruction cache, and it is altered, the changed code will
  81. not be noticed. Thus existing self-modifying code and dynamic code creation
  82. or loading will generally not work.
  83.  
  84. RISC OS 3.7 provides a call to synchronise the instruction and data caches,
  85. but this is a slow operation on the StrongARM. Self-modifying code should
  86. therefore be avoided. The most common failures here arise from custom SWI
  87. veneers that assemble code on the stack, dynamic code loading and linking
  88. and custom code squeezing and encryption.
  89.  
  90. The other significant StrongARM change is that storing the PC to memory
  91. (using STR or STM) stores PC+8 rather than PC+12. This can generally be
  92. catered for by judicious use of NOPs to allow for both possibilities. This
  93. affects, for example, APCS stack backtraces and vector claimants (the
  94. example code on PRM page 1-107 will not work, for example).
  95.  
  96. There are other differences that are only likely to be encountered by
  97. low-level system code.
  98.  
  99. Most applications will run unmodified on StrongARM, especially those written
  100. in C and BASIC, but some code will inevitably need modification.
  101.  
  102. Guidelines for Authoring Software for StrongARM
  103. -----------------------------------------------
  104. * Code written in C or BASIC will generally work, but see issues below.
  105.  
  106. * Code using the shared C library or Toolbox is generally fine. Using
  107.   RISCOS_Lib may cause problems, depending on the variant - re-linking to a
  108.   revised implementation will typically be sufficient. Anything linked with
  109.   ANSILib will not work. Products should _not_ be linked with ANSILib.
  110.  
  111. * Proprietary code squeezers may cause problems. Unsqueezed code or standard
  112.   squeezed code with AIF headers (eg code produced with our Squeeze system) is
  113.   generally fine. A new module, UnsqueezeAIF, detects squeezed images and
  114.   unsqueezes them itself with a negligible performance penalty.
  115.  
  116. * An application patcher will be supplied with RISC OS 3.7 that is capable
  117.   of detecting some known StrongARM-incompatible code sequences in an AIF
  118.   image and replacing them before the image is executed. This is only a
  119.   temporary solution though. If you find your software works only because the
  120.   patcher is patching it, you should modify it so it does not need patching.
  121.  
  122. * All Absolute files must have valid AIF headers. Absolute files without AIF
  123.   headers and untyped files are deprecated.
  124.   
  125. When writing in Assembler:
  126.  
  127. * Any self-modifying code or dynamically generated code is a problem. RISC
  128.   OS 3.7 provides a SWI to support StrongARM synchronisation to dynamic code,
  129.   but the performance penalty is typically severe; cleaning the data cache
  130.   will take some time, and the entire instruction cache must be flushed.
  131.   Hence, most cases of dynamic code can no longer be justified, and should be
  132.   reimplemented in a static manner. One common reason for dynamic code is the
  133.   calling of a SWI by SWI code passed in a register. RISC OS 3.7 provides a
  134.   new SWI which implements this in an entirely static manner.
  135.  
  136. * The StrongARM pipeline is generally not a problem (even though it is now 5
  137.   levels deep rather than 3). The main issue is storing of the PC to memory
  138.   using STR and STM; this now stores PC+8 instead of PC+12. Code should be
  139.   made to work whether PC+8 or PC+12 is stored (so that ARM 6,7 are still
  140.   supported). Use of the PC in data processing instructions (MOV, ADD etc)
  141.   remains unaltered on StrongARM.
  142.  
  143. * STRB PC has an undefined result. This has sometimes been used as a
  144.   shortcut for storing a non-zero semaphore value in speed critical code. This
  145.   instruction should no longer be used. Use STR PC or STRB of some other
  146.   register.
  147.  
  148. Other differences at the assembler level, which affect RISC OS itself but
  149. are unlikely to affect applications are:
  150.  
  151. * StrongARM does not support 26 bit configuration. It does support 26 bit
  152.   mode within a 32 bit configuration.
  153.  
  154. * The control of architecture functions via coprocessor #15 is significantly
  155.   different. The requirements for context switching are significantly more
  156.   complex.
  157.  
  158. * The 'abort timing' (definition of values in affected registers) for data
  159.   aborts has changed.
  160.  
  161. At the hardware level:
  162.  
  163. * When storing a byte, previous ARMs replicate the byte across the entire 32
  164.   bit data bus. StrongARM only outputs the byte on the relevant byte lane. The
  165.   StrongARM processor card implements a compatibility fix for pre-Risc PC
  166.   style podules as follows: bytes stored to word aligned addresses (byte 0)
  167.   will be replicated on byte 2.  This should allow most podules to work
  168.   without firmware changes.
  169.  
  170. Backwards compatibility:
  171.  
  172. * Much StrongARM-ready code (especially in libraries, such as the
  173.   aforementioned revised RISC_OSLib) may use the new SWI-calling mechanism.
  174.   Therefore a new module "CallASWI" will be made available for use on RISC OS
  175.   3.1, 3.5 and 3.6 to provide the SWIs OS_CallASWI, OS_CallASWIR12,
  176.   OS_PlatformFeatures and OS_SynchroniseCodeAreas.
  177.  
  178. Changes to Existing SWIs
  179. ------------------------                       
  180. OS_MMUControl (page 5a-70)
  181.  
  182.     This SWI has a new reason code, to support platform independent cache 
  183.     and/or TLB flushing:
  184.  
  185. OS_MMUControl 1 (SWI &6B)
  186.  
  187.     Cache flush request
  188.     
  189. On entry
  190.     R0 = reason code and flags
  191.            bits 0-7  = 1 (reason code)
  192.            bits 8-28 reserved (must be zero)
  193.            bit 29 set if flush of single entry, else complete flush
  194.            bit 30 set if processor TLBs are to be flushed
  195.            bit 31 set if processor caches are to be flushed
  196.     R1 = logical address, if R0 bit 29 set
  197.  
  198. On exit
  199.     R0,R1 preserved
  200.  
  201. Interrupts
  202.     Interrupt status is not altered
  203.     Fast interrupts are enabled
  204.  
  205. Processor mode
  206.     Processor is in SVC mode
  207.  
  208. Re-entrancy
  209.     SWI is not re-entrant
  210.     
  211. Use
  212.     This call implements platform independent cache and/or TLB flushing.
  213.     
  214. WARNING: This SWI reason code is only intended for occasional, unavoidable
  215. requirements for cache/TLB flushing. You should respect the performance
  216. implications of this SWI reason code, in a similar way to SWI
  217. OS_SynchroniseCodeAreas.
  218.              
  219.  Currently, bit 29 is ignored, so that only whole flushing of caches and/or
  220. TLBs are supported. A cache will be cleaned before flushing, where the
  221. processor supports a write-back cache.
  222.  
  223.  This reason code is not re-entrant. Interrupts are not disabled during the
  224. flush, so the cache or TLB flush can only be considered to be complete with
  225. respect to logical addresses that are not currently involved in interrupts.
  226.  
  227.  
  228. OS_File 12, 14, 16 and 255 (page 2-40)
  229.  
  230. If R3 bit 31 is set on entry, the file being loaded will be treated as code,
  231. and the relevant area will be synchronised using OS_SynchroniseCodeAreas if
  232. necessary.
  233.  
  234. A filetype for Code (&F95) has been allocated, with the intention that it be
  235. a parallel of Data (&FFD), and when it is loaded a synchronise is
  236. automatically performed. However this functionality has not been implemented
  237. in RISC OS 3.70; you will still need to set bit 31 as described above.
  238.  
  239. Note that the *Load command calls OS_File 255 with bit 31 of R3 set, so no
  240. synchronise is required. This is to aid backwards compatibility; if no
  241. synchronisation is required, then use OS_File 255 directly.
  242.  
  243.  
  244. DMA (page 5a-83)
  245.  
  246. The DMA Manager now marks pages uncacheable for both transfers from device
  247. to memory and transfers from memory to device. This is to ensure StrongARM's
  248. write-back cache is cleaned before the transfer starts.
  249.  
  250. New Service Calls
  251.  
  252. Service_UKCompression (Service call &B7)
  253.  
  254.     An application that may need unsqueezing/patching has just been loaded
  255.     
  256. On entry
  257.     R0 = subreason code
  258.            0 -> first pass (unsqueeze)
  259.            1 -> second pass (patch)
  260.            all other codes reserved
  261.     R1 = &B7 (reason code)
  262.     R2 = load address
  263.     R3 = size
  264.     R4 = execute address
  265.     R5 = filename (as passed to FileSwitch, not canonicalised)
  266.  
  267. On exit
  268.     R1 preserved to pass on, or 0 to claim if you know you have performed
  269.   all required unsqueezeing/patching for this pass.
  270.  
  271.     R3 may be modified to indicate an altered size (eg after unsqueezing)
  272.     R4 may be modified to specify an new execute address
  273.     Other registers preserved
  274.  
  275. Use
  276.     This service call is passed around when an Absolute (&FF8) file is run.
  277.     The sequence of events is as follows.
  278.     
  279.       1) The image is loaded.
  280.       2) If it does not contain an unsqueezed AIF header, then
  281.          Service_UKCompression 0 is issued.
  282.       3) Service_UKCompression 1 is issued.
  283.       4) OS_SynchroniseCodeAreas is called.
  284.     
  285. Therefore unsqueezers and patchers need not do any synchronisation except
  286. that necessary for their internal working (they may want to alter some code,
  287. synchronise, and call it before returning from the service call).
  288.      Two modules are supplied with RISC OS 3.7 that use this service call:
  289.     
  290.  UnsqueezeAIF will unsqueeze squeezed AIF images on the first pass, and
  291. squeezed non-AIF images by code modification (so the unsqueeze will not
  292. occur until after stage 5 above)
  293.     
  294.  AppPatcher will patch squeezed and unsqueezed AIF images containing certain
  295. common code sequences that are known to fail on StrongARM.
  296.  
  297. Scanning an application for code sequences is a relatively slow operation.
  298. Therefore a bit has been allocated in the AIF header to indicate that a
  299. program is "StrongARM-ready". If bit 31 of the 13th word of the AIF  header
  300. (ie bit 31 of location &8030 in the loaded image) is set, the patching stage
  301. will be skipped (in RISC OS 3.7 by AppPatcher claiming the service call and
  302. doing nothing; in a future version of RISC OS FileSwitch may not issue the
  303. service call). The program will still be automatically unsqueezed; it is
  304. recommended that you continue to use the existing Squeeze utility provided
  305. with Acorn C/C++, and rely on the operating system to unsqueeze the image
  306. for you.
  307.    
  308. Service_ModulePreInit (Service call &B9)
  309.  
  310.     A module is about to be initialised
  311.     
  312. On entry
  313.     R0 = module address
  314.     R1 = &B9 (reason code)
  315.     R2 = module length
  316.  
  317. On exit
  318.     R1 preserved to pass on
  319.  
  320. Use
  321.     This service is called just before a module is initialised. When a
  322.     module is *RMLoaded:
  323.     
  324.        1) The module is loaded into memory
  325.        2) The module is unsqueezed if necessary
  326.        3) Service_ModulePreInit is called
  327.        4) OS_SynchroniseCodeAreas is called
  328.     
  329.     This service call is intended to allow run-time patching of modules.
  330.     
  331.     
  332. New SWIs
  333. --------
  334. OS_PlatformFeatures (SWI &6D)
  335.  
  336.     Determine various features of the host platform
  337.  
  338. On entry
  339.     R0 = reason code (bits 0-15) and flags (bits 16-31, reason code
  340.          specific)
  341.     Other registers depend upon the reason code
  342.  
  343. On exit
  344.     Registers depend upon the reason code
  345.  
  346. Interrupts
  347.     Interrupt status is unaltered
  348.     Fast interrupts are enabled
  349.     
  350. Processor mode
  351.     Processor is in SVC mode
  352.  
  353. Re-entrancy
  354.     SWI is re-entrant
  355.  
  356. Use
  357.     This new SWI is used to determine various feaures of the platform that
  358.     the application or module is running on.
  359.  
  360.     The particular action of OS_PlatformFeatures is given by the reason code
  361.     in bits 0-15 of R0 as follows:
  362.     
  363.         R0    Action
  364.           0     Read code features
  365.  
  366. OS_PlatformFeatures 0 (SWI &6D)
  367.  
  368.     Read code features
  369.  
  370. On entry
  371.     R0 = 0 (reason code); all flags are reserved, so bits 16-31 must be
  372.     clear
  373.  
  374. On exit
  375.     R0 = bit mask of features:
  376.            Bits     Meaning
  377.            0        Must tell OS when code areas change (by calling
  378.                     OS_SynchroniseCodeAreas)
  379.            1        Enabling, then immediately disabling interrupts will not
  380.                     give interrupts a chance to occur
  381.            2        Must be in 32 bit mode to read hardware vectors
  382.            3        Storing PC to memory (eg with STR or STM) stores PC+8
  383.                     rather than PC+12
  384.            4        Data aborts occur with 'full early' timing (ie. as
  385.                     defined by ARM Architecture 4)
  386.                                 
  387.    If bit 1 of R0 set then                             
  388.      R1 -> routine to call between IRQ enable & disable.
  389.  
  390. Use
  391.     This call determines features of the host processor's instruction set.
  392.     
  393.  Platforms running ARM 6 or 7 cores will return with R0 bits 0-4 clear;
  394. platforms running StrongARM will return with bits 0-4 set in RISC OS 3.7
  395. (but bit 2 should in fact be clear). For compatibility with older versions
  396. of RISC OS, you should call this SWI in the X form; if V is set on return
  397. and the error is 'SWI not known', then this can be taken as equivalent to a
  398. return with R0 bits 0-4 clear. Note that the easiest way to deal with the
  399. PC+8/PC+12 issue across all platforms is to make sure that the code is valid
  400. in either case (typically with judicious use of NOPs).
  401.  
  402. The routine pointed to by R1 is suitable for calling from any 26-bit
  403. mode; it preserves all flags and registers, and is reentrant. It should be
  404. called as follows:
  405.      
  406. LDR    R0, irqroutine   ; Load address previously stored in workspace
  407. MOV    R14, PC          ; Get return address of PC+8
  408. MOV    PC, R0           ; Call routine
  409. ...                     ; Code returns here
  410.   
  411.  
  412. OS_SynchroniseCodeAreas (SWI &6E)
  413.  
  414.     Inform the OS that code has been altered
  415.  
  416. On entry
  417.     R0 = flags
  418.            bit 0 clear  Entire address space to be synchronised.
  419.            bit 0 set    Address range to be synchronised.
  420.            bits 1-31    Reserved
  421.  
  422.     If R0 bit 0 is set then:
  423.         R1 = low address of range (word aligned)
  424.         R2 = high address (word aligned, inclusive)
  425.  
  426. On exit
  427.     R0-R2 preserved
  428.  
  429. Interrupts
  430.     Interrupt status is not altered
  431.     Fast interrupts are enabled
  432.  
  433. Processor mode
  434.     Processor is in SVC mode
  435.  
  436. Re-entrancy
  437.     SWI is not re-entrant
  438.  
  439. Use
  440.     This new SWI informs the OS that code has been newly generated or
  441. modified in memory, before any attempt is made to execute the code.
  442.  
  443. WARNING: This SWI is only intended for synchronisation with unavoidable use
  444. of dynamic code, because of the potential for large performance penalties.
  445. There is no longer any justification in RISC OS applications for frequent
  446. code modification. This call  must never be used in an interrupt routine.
  447. Examples of  reasonable use include one-off loading, relocation etc. of 
  448. subsidiary code or libraries.
  449.  
  450.       When using this SWI, you should use the ranged variant wherever
  451. possible, in order to minimise the performance penalty.
  452.  
  453.      The call may take a long time to return (up to around 0.5ms), so it
  454. should not be called with interrupts disabled.
  455.  
  456.  For compatibility with older versions of RISC OS, you should either have
  457. determined (with OS_PlatformFeatures) that this SWI should not be called, 
  458. or always call this SWI in the X form, and ignore any error returned. On
  459. platforms that do not require code synchronisation (as indicated by
  460. OS_PlatformFeatures 0), OS_SynchroniseCodeAreas will do nothing.
  461.  
  462.  Note that standard loading of applications or modules (and the standard C
  463. overlay system) are automatically handled by the OS, and do not require
  464. synchronisation. This may be defeated by custom squeezing, failure to use a
  465. standard AIF header for applications, and so on.
  466.  
  467. OS_CallASWI (SWI &6F)
  468.  
  469.    Call a run-time determined SWI
  470.  
  471. On entry
  472.     R0-R9 as required for target SWI
  473.     R10 = target SWI number
  474.  
  475. On exit
  476.     R0-R9 as defined by target SWI
  477.     R10 preserved
  478.  
  479. Interrupt status
  480.    As defined by target SWI
  481.  
  482. Processor mode
  483.    As defined by target SWI
  484.  
  485. Re-entrancy
  486.    As defined by target SWI
  487.  
  488. Use
  489.     This new SWI allows a target SWI number to be determined at run time,
  490. and passed in a register. This removes the need for a common idiom of
  491. dynamic code, in language library SWI veneers for example. In an APCS-R 
  492. library, OS_CallASWIR12 may be more appropriate (see below).
  493.  
  494.  Note that OS_CallASWI is merely an alias for calling the target SWI. It has
  495. no entry/exit conditions of its own, except for the special use of R10. To
  496. call a target SWI with X bit set, us the X form of the SWI number in R10;
  497. there is no distinction between OS_CallASWI and XOS_CallASWI.
  498.  
  499.  You cannot call OS_CallASWI or OS_CallASWIR12 via OS_CallASWI, since there
  500. is no defined final target SWI in this case.
  501.  
  502.  You cannot usefully call OS_BreakPt or OS_CallAVector using OS_CallASWI, as
  503. OS_CallASWI will corrupt the processor flags before entering the target SWI.
  504.     
  505.  For future compatibility, you should always use this SWI in preference to
  506. any local construction for calling a SWI by number. For compatibility with
  507. older versions of RISC OS, a new CallASWI module will be made available (see
  508. below).
  509.     
  510.  Note that this SWI calling mechanism is almost certainly faster than any
  511. other alternative implementation, including the original _kernel_swi  and
  512. _swix code contained in older versions of the SharedCLibrary. The new
  513. SharedCLibrary now simply uses OS_CallASWIR12 for _kernel_swi and  _swix.
  514.     
  515.  OS_CallASWI cannot be called from BASIC as BASIC only passes registers
  516. R0-R7 via its SYS instruction. It would not be useful anyway.
  517.  
  518. OS_AMBControl (SWI &70)
  519.  
  520.     This SWI is for system use only; you must not use it in your own code.
  521.  
  522. OS_CallASWIR12 (SWI &71)
  523.  
  524.     Call a run-time determined SWI
  525.  
  526. On entry
  527.     R0-R9 as required for target SWI
  528.     R12 = target SWI number
  529.  
  530. On exit
  531.     R0-R9 as defined by target SWI
  532.     R12 preserved
  533.  
  534. Interrupt status
  535.    As defined by target SWI
  536.  
  537. Processor mode
  538.    As defined by target SWI
  539.  
  540. Re-entrancy
  541.    As defined by target SWI
  542.  
  543. Use
  544.     This call is identical to OS_CallASWI, except that it uses R12 to
  545. specify the target SWI. This may be more convenient in some environments. In
  546. particular under APCS-R, R10 is the stack limit pointer, which must be
  547. preserved at all times; if a SWI called using OS_CallASWI were to abort or
  548. generate an error the run-time library would usually examine R10 and decide
  549. that it had no stack to handle the abort or error. Therefore APCS-R
  550. libraries must use OS_CallASWIR12 (R12 being a scratch register  under
  551. APCS-R).
  552.  
  553. The CallASWI Module
  554. -------------------
  555. The CallASWI module provides support under RISC OS 3.1, 3.5 and 3.6 for the
  556. following SWIs:
  557.  
  558.               OS_CallASWI
  559.               OS_CallASWIR12
  560.               OS_PlatformFeatures
  561.               OS_SynchroniseCodeAreas
  562.  
  563. This will enable application programmers and library writers to use the new
  564. calls freely without any worries about backwards compatibility. There is no
  565. performance penalty for the use of these SWIs via the CallASWI module. One
  566. slight caveat is that older machines will not know the names of these SWIs;
  567. they would have to be called by number from BASIC.
  568.  
  569. Performance issues
  570. ------------------
  571. The StrongARM has significantly different performance characteristics to
  572. older ARM processors. It is clocked 5 times faster than any previous ARM,
  573. and many instructions execute in fewer cycles. In particular
  574.  
  575.     *  B/BL take 2 cycles, rather than 3
  576.     *  MOV PC,Rn and ADD PC,PC,Rn,LSL #2 etc take 2 cycles rather than 3
  577.     *  LDR takes 2 cycles (from the cache) rather than 3, and will take only
  578.        1 cycle if the result is not used inthe next instruction.
  579.     *  STR takes 1 cycle rather than 2, if the write buffer isn't full
  580.     *  MUL/MLA take 1-3 cycles rather than 2-17 cycles.
  581.     *  Many instructions will in fact take only one cycle provided the
  582.        result is not used in the next instruction.
  583.  
  584. For fuller information see the StrongARM Technical Reference Manual,
  585. available from Digital Semiconductor's WWW site (currently at
  586. http://www.digital.com/info/semiconductor/dsc-strongarm.html)
  587.  
  588. The StrongARM's cache and write buffer are also significantly better than
  589. previous ARMs, allowing an average fivefold speed increase, despite the
  590. unaltered system bus. Pumping large amounts of data will still be limited by
  591. the system bus, but advantage can be taken of the write buffer to interleave
  592. a large amount of processing with memory accesses. For example on StrongARM
  593. it is quicker to plot a 4bpp sprite to a 32bpp mode than to plot a 32bpp
  594. sprite to a 32bpp mode; the latter case is pure data transfer, while the
  595. former is less data transfer with interleaved (ie effectively free)
  596. processing.
  597.  
  598. The long cache lines of the ARM710 and StrongARM can impact performance. A
  599. random read or instruction fetch from a cached area will load 8 words into
  600. the cache; this can make traversal of a long linked list inefficient. It is
  601. also often worth aligning code to an 8-word boundary. In current versions of
  602. RISC OS modules are loaded at an address 16*n+4. Future versions of RISC OS
  603. will probably load modules at an address 32*n+4, so it is worth aligning
  604. your service call entries appropriately in preparation for this change.
  605.  
  606. Two significant disadvantages of StrongARM over previous processors are:
  607.  
  608. 1) Burst reads are not performed from uncached areas. In particular this
  609.    means that reads from the screen are slower on the StrongARM than on
  610.    previous ARMs. A future version of RISC OS may address this by marking
  611.    the screen cacheable before reading (eg in a block copy operation). Also,
  612.    burst writes are not performed to unbuffered areas.
  613.  
  614. 2) Code modification is expensive. You can modify code, but a complete
  615.    SynchroniseCodeAreas can take of the order of half a millisecond (ie
  616.    100000 processor cycles) to execute, and will flush the entire
  617.    instruction cache. Thus use of self-modifying code is strongly
  618.    deprecated; a static alternative will almost always be faster.
  619.    Synchronisation of a single word (eg modifying a hardware vector) is
  620.    cheaper (of the order of 100 processor cycles) but still requires the
  621.    whole instruction cache to be flushed.
  622.  
  623. Note that future processors will no doubt have different performance
  624. characteristics again; you shouldn't optimise your code too much for one
  625. particular architecture at the expense of others. However, hopefully you
  626. will now have a better idea how to get better performance from your
  627. StrongARM.
  628.  
  629. Use of FIQs
  630. -----------
  631. FIQ usage is now deprecated. When you modify the FIQ vector, you will need
  632. to synchronise the code. However, as FIQ routines cannot call SWIs you are
  633. unable to call OS_SynchroniseCodeAreas. For StrongARM compatibility we
  634. recommend you use the FIQ vector as follows:
  635.  
  636.      0000001C: LDR PC,&00000020
  637.      00000020: <address of FIQ handler>
  638.      
  639. and use the following code to do the synchronise manually when you write the
  640. instruction at location &1C (no synchronise is required when you alter the
  641. address at &20).
  642.  
  643.         .
  644.         <alter FIQ vector>
  645.         .
  646.         MRC    CP15,0,R0,C0,C0           ; get processor ID
  647.         AND    R0,R0,#&F000
  648.         TEQ    R0,#&A000
  649.         BNE    NotStrongARM
  650.         MOV    R0,#&1C           
  651.         MCR    CP15,0,R0,C7,C10,1        ; clean data cache entry for FIQ vector
  652.         MOV    R0,#0
  653.         MCR    CP15,0,R0,C7,C10,4        ; drain write buffer
  654.         MCR    CP15,0,R0,C7,C5           ; flush whole instruction cache
  655.   NotStrongARM
  656.         .
  657.         .
  658.         .
  659.  
  660. If you want to write a complete FIQ handler into locations &1C to &FC, you
  661. should clean each 32-byte data cache line containing written code thus:
  662.  
  663.   replace
  664.         MOV     R0,#&1C
  665.         MCR     CP15,0,R0,C7,C10,1
  666.         
  667.   with
  668.         MOV     R0,#&E0              ; clean complete FIQ area
  669.   01    MCR     CP15,0,R0,C7,C10,1   ; 32 bytes (1 cache line) at a time
  670.         SUBS    R0,R0,#&20
  671.         BGE     %BT01
  672.         
  673. This will usually be slower than the approach recommended above.
  674.  
  675. This is, of course, not a future-proof solution. We recommend that no new
  676. products use FIQ code. If you feel you have a pressing need to use FIQs,
  677. contact ART Developer Support for advice.
  678.  
  679. Miscellaneous Changes in RISC OS 3.7 Not Directly Related to StrongARM
  680. ----------------------------------------------------------------------
  681. The Kernel
  682. ----------
  683. The System ROM is now marked read-only in the MMU page tables of machines
  684. with an ARM7 or later processor. Attempts to write to ROM space will cause a
  685. data abort.
  686.  
  687. The kernel is now aware of multiple applications (see below).
  688.  
  689. FileSwitch
  690. ----------
  691. FileSwitch now supports 2048-byte buffers (see FSEntry_Open on page 2-531).
  692.  
  693. The Window Manager
  694. ------------------
  695. The Window Manager has now delegated application memory management to the
  696. kernel. The kernel is now aware of multiple application memory blocks (AMBs)
  697. and pages them in and out when requested by the Window Manager. This
  698. improves task switching performance, as the kernel is able to remap AMBs far
  699. faster than the Window Manager was able to using OS_SetMemMapEntries.
  700.  
  701. The Font Manager
  702. ----------------
  703. The Font Manager now supports background blending in modes with 256 colours
  704. or more. This blending causes the anti-aliased pixel data to be blended with
  705. the background colour rather than using the fixed colour specified in the
  706. various colour setting SWIs.
  707.  
  708. To use the blending, you should set bit 11 of R2 in the call to Font_Paint.
  709. However, you need to ensure the following:
  710.  
  711.  1) The font colours specify that there is >= 1 anti-aliasing colour,
  712.     otherwise the Font Manager will attempt to paint from 1bpp cache data
  713.     rather than the 4bpp anti-aliased data.
  714.   
  715.      
  716.  2) The Font Manager you are calling supports this bit, as previous versions
  717.     of the Font Manager will complain if they find this bit set. You should
  718.     call Font_CacheAddr to check the version of the Font Manager your
  719.     application is running on, and only set  the bit on Font Manager 3.35 or
  720.     later.
  721.  
  722. There is a noticeable speed hit in using blending, so you should not use it
  723. if you know you are plotting onto a uniform background.
  724.  
  725. Blending should not be activated during printing.
  726.  
  727. Debugger
  728. --------
  729. SWI Debugger_Disassemble is now aware of the complete ARMv4 instruction set.
  730.  
  731. Note that the LDRH, LDRSH and STRH instructions are not supported by the
  732. Risc PC memory system; although they will often work in a cached area
  733. because memory is accessed a 4 or 8 words at a time, they will not work
  734. reliably. LDRSB, MULL and MLAL may be freely used (except of course they
  735. won't be backwards-compatible). Contrary to the information in the Acorn
  736. Assembler manual about the ARM7M, the long multiply instructions can be used
  737. in 26-bit modes.
  738.  
  739. Econet
  740. ------
  741. A StrongARM-compatible Econet module has been placed in the System ROM,
  742. rather than the RiscPC/A7000 Econet card firmware being upgraded.
  743.  
  744. The Internet module
  745. -------------------
  746. The Internet module supplied with RISC OS 3.70 is a major new version based
  747. on FreeBSD, a 4.4BSD-derived UNIX. It offers improved performance, and a
  748. wider API, including support for multicasting and T/TCP. All calls
  749. documented in chapter 123 of the Programmer's Reference Manual continue to
  750. work as documented, but some of the lower-level socketioctl calls,
  751. particularly those to do with route manipulation have been withdrawn. More
  752. details will be made available later.
  753.  
  754. A revised !Internet application is supplied as part of the !Boot structure
  755. and a new application provides an easy interface for configuring the various
  756. networking components built in to RISC OS 3.7
  757.  
  758. Access
  759. ------
  760. Access Plus is now in the System ROM, instead of being supplied in the
  761. System application on the hard disc.
  762.  
  763. AUN
  764. ---
  765. A new subreason code of Service_InternetStatus has been added;
  766. Service_InternetStatus 1 is issued when the Net module receives a network
  767. map from a gateway station.
  768.